Large enterprise environments require large amounts of data processing power and data storage capacity to support creation and exchange of large amounts of data among personnel involved with the enterprise. Such data processing power and data storage capacity is often provided through a large data processor or network of processors or servers serving a large network of client computers or terminals which may also provide some local data storage and data processing capacity. In such environments, additional processors or servers are added and/or upgraded with substantial frequency as data processing and communication requirements increase over the duration of the enterprise. Since the duration of an enterprise may extend over many years, it is not uncommon for substantial portions of the data processing capacity to be replaced due to obsolescence, alteration of system architecture, changes in functions of the enterprise and the like. When such changes, upgrades and additions to the data processing system are made (sometime collectively referred to as transformation projects), it is necessary for new equipment to be operated with equipment previously existing in the system (often referred to as legacy systems) and have the capability of seamlessly exchanging data between portions of the system.
When a large transformation project is performed, a substantial period of time is required to ascertain that newer portions of the system are working together properly with or prior to decommissioning of legacy portions of the system and, importantly, that data is properly usable by all portions of the system. Sometimes conversion of data for use by different portions of the system may also be required. During such a period the volume of data transferred between different portions of the system may be greatly increased as operation of the system is verified and any problems that are encountered are located and corrected. However, such increased volume of communicated data must nevertheless be carried over network infrastructure that is scaled in capacity for normal enterprise operations.
Much of the data messages communicated within an enterprise is coded into a so-called mark-up language in which the data is placed in a field that is defined and the data identified by a so-called tag that accompanies the data in the message. A number of such languages are known such as hypertext mark-up language (HTML), structured query mark-up language (SQML) and extensible mark-up language (XML). These languages provide the advantage that data contained in messages can be retrieved and utilized (e.g. formatted, presented, suppressed, decrypted/decoded in different ways and the like) in any desired manner and to accommodate any of many diverse forms of data in accordance with the tags defining the fields and such controls need not be transmitted in the message. Further, the tags may be freely chosen to be meaningful and thus can be of substantial assistance to a viewer of the message in detecting problems in the transmission of data and determining the location (e.g. at the transmitting or receiving end of a communication link) of the problem by relatively simple inspection by trained personnel. The collection of tags used for a given group of messages is referred to as a schema and it is not uncommon for a schema to define all tags that can be used in any message that is communicated in a given system. However, the information contained in tags can and often does exceed the length of the data itself, particularly where the message is encoded using XML that provides for both a start tag and an end tag to be applied to each datum.
Several approaches to making XML messages shorter have been proposed including XML compression such as the elimination of end tags and so-called binary coded XML in which short but non-informative tags comprising only one or a very few characters are used. However, any of these known techniques poses a problem in regard to usability, particularly for quick recognition and location of a problem with data synchronization.